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Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://ipr.etsi.org) . 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 

This Technical Specification (TS) has been produced by ETSI Technical Conmiittee Satellite Earth Stations and 
Systems (SES). 

The present document is part 1 of a multi-part deliverable covering the Air Interface for S-band Mobile Interactive 
Multimedia (S-MIM), as identified below: 

Part 1 : " General System Architecture and Configurations ' ' ; 

Part 2: "Forward Link Subsystem Requirements" ; 

Part 3: "Physical Layer Specification, Return Link Asynchronous Access"; 

Part 4: "Physical Layer Specification, Return Link Synchronous Access"; 

Part 5: "Protocol Specifications, Link Layer"; 

Part 6: "Protocol Specifications, System Signalling". 



Introduction 



The S-MIM system specified herein is designed to provide: 

• Interactive mobile broadcast services. 

• Messaging services for handhelds and vehicular terminals, capable of serving millions of terminals due to a 
novel optimized air-interface in the return link. 

• Real-time emergency services such as voice and file transfer, mainly addressing institutional users 
on-the-move such as fire brigades, civil protection, etc. 

Inside the S-band, the 2 GHz MSS band is of particular interest for interactive multimedia, since it allows two-way 
transmission. Typically, the DVB-SH standard [i.8] is applied for broadcast transmission of user services; ESDR [i.6] or 
DVB-NGH [i.l2] standards are other alternatives. Essential requirements under the R&TTE directive are covered by the 
harmonized standard EN 302 574 [i.3], [i.4] and [i.5]. 

The present document supersedes the previous version of the document and is recommended for new implementations. 
In case DVB-SH is used in the forward link, the changes with respect to the previous version are backward compatible. 

The technology applied has been developed in the framework of the ESA funded project "DENISE" (ESTEC/Contract 
Number 22439/09/NL/US). 
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Scope 



The present document specifies the S-MIM (S-band Mobile Interactive Multimedia) system in which a standardized 
S-band satellite mobile broadcast system is complemented by the addition of a return channel. 

The present document is part 1 of the multi-part deliverable and defines the general S-band Mobile Interactive 
Multimedia (S-MIM) system architecture and configurations. 

The other parts are listed in the foreword. 



2 References 

References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the 
referenced document (including any amendments) applies. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http://docbox.etsi.org/Reference . 

NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee 
their long term validity. 

2.1 Normative references 

The following referenced documents are necessary for the application of the present document. 

[1] ETSI TS 102 721-2: "Satellite Earth Stations and Systems; Air Interface for S-band Mobile 

Interactive Multimedia (S-MIM); Part 2: Forward Link Subsystem Requirements". 

2.2 Informative references 

The following referenced documents are not necessary for the application of the present document but they assist the 
user with regard to a particular subject area. 

[i.l] ETSI TS 102 584: "Digital Video Broadcasting (DVB); DVB-SH Implementation Guidelines". 

[i.2] IEEE Journal on Selected Areas in Communications: "Bandlimited Quasi-Synchronous CDMA: A 

Novel Satellite Access Technique for Mobile and Personal Communications Systems". 
R. De Gaudenzi, C. EHa, R. Viola, 1992. 

[i.3] ETSI EN 302 574-1: "Satellite Earth Stations and Systems (SES); Harmonized standard for 

satellite earth stations for MSS operating in the 1 980 MHz to 2 010 MHz (earth-to-space) and 
2 170 MHz to 2 200 MHz (space-to-earth) frequency bands; Part 1: Complementary Ground 
Component (CGC) for wideband systems: Harmonized EN covering the essential requirements of 
article 3.2 of the R&TTE Directive". 

[i.4] ETSI EN 302 574-2: "Satellite Earth Stations and Systems (SES); Harmonized standard for 

satellite earth stations for MSS operating in the 1 980 MHz to 2 010 MHz (earth-to-space) and 
2 170 MHz to 2 200 MHz (space-to-earth) frequency bands; Part 2: User Equipment (UE) for 
wideband systems: Harmonized EN covering the essential requirements of article 3.2 of the 
R&TTE Directive". 

[i.5] ETSI EN 302 574-3: "Satellite Earth Stations and Systems (SES); Harmonized standard for 

satellite earth stations for MSS operating in the 1 980 MHz to 2 010 MHz (earth-to-space) and 
2 170 MHz to 2 200 MHz (space-to-earth) frequency bands; Part 3: User Equipment (UE) for 
narrowband systems: Harmonized EN covering the essential requirements of article 3.2 of the 
R&TTE Directive". 



ETSI 



7 ETSI TS 1 02 721 -1 V1 .2.1 (201 3-08) 

[i.6] ETSI EN 302 550 (all parts and sub-parts): "Satellite Earth Stations and Systems (SES); Satellite 

Digital Radio (SDR) Systems". 

[i.7] ETSI TS 102 824 (VI. 1.1): "Digital Video Broadcasting (DVB); Remote Management and 

Firmware Update System for DVB IPTV Services (Phase 2)". 

[i.8] ETSI TS 102 585: "Digital Video Broadcasting (DVB); System Specifications for Satellite 

services to Handheld devices (SH) below 3 GHz". 

[i.9] ETSI TS 102 721-3: "Satellite Earth Stations and Systems; Air Interface for S-band Mobile 

Interactive Multimedia (S-MIM); Part 3: Physical Layer Specification, Return Link Asynchronous 

Access". 

[i.lO] ETSI TS 102 721-4: "Satellite Earth Stations and Systems; Air Interface for S-band Mobile 

Interactive Multimedia (S-MIM); Part 4: Physical Layer Specification, Return Link Synchronous 

Access". 

[i.l 1] ETSI TS 102 721-5: "Satellite Earth Stations and Systems; Air Interface for S-band Mobile 

Interactive Multimedia (S-MIM); Part 5: Protocol Specifications, Link Layer". 

[i.l2] DVB BlueBook A160: "Next Generation broadcasting system to Handheld, physical layer 

specification (DVB-NGH)". 

[i.l3] ETSI TS 102 721-6: "Satellite Earth Stations and Systems; Radio interface for S-band Mobile 

Interactive Multimedia (S-MIM); Part 6: "Satellite Earth Stations and Systems; Air Interface for 
S-band Mobile Interactive Multimedia (S-MIM); Part 6: Protocol Specifications, System 
Signalling". 



3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply: 

2 GHz MSS band: 1 980 MHz to 2 010 MHz (earth-to-space) and 2 170 MHz to 2 200 MHz (space-to-earth) frequency 
bands 

NOTE: These paired bands are assigned to MSS. 

architecture: abstract representation of a communications system 

NOTE: Three complementary types of architecture are defined: 

■ Functional Architecture: the discrete functional elements of the system and the associated logical 
interfaces. 

■ Network Architecture: the discrete physical (network) elements of the system and the associated 
physical interfaces. 

■ Protocol Architecture: the protocol stacks involved in the operation of the system and the 
associated peering relationships. 

collector: terrestrial components (Complementary Ground Component) that "collect" return link transmissions from 
terminals and forward them towards the ground segment 

control plane: plane that has a layered structure and performs the access control and connection control functions; it 
deals with the signalling necessary to access to services, set up, supervise and release calls and connections 

flow (of IP packets): traffic associated with a given connection-oriented, or connectionless, packet sequence having the 
same 5-tuple of source address, destination address. Source Port, Destination Port and Protocol type 
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management plane: plane that provides two types of functions, namely Layer Management and plane management 
functions: 

• plane management functions: performs management functions related to a system as a whole and provides 
co-ordination between all the planes. Plane management has no layered structure 

• layer Management functions: performs management functions relating to resources and parameters residing 
in its protocol entities 

repeater: terrestrial components (Complementary Ground Component) that (mainly) repeat the satellite signal in the 
forward link 

S-band: equivalent to 2 GHz MSS band 

user plane: plane that has a layered structure and provides user information transfer, along with associated controls 
(e.g. flow control, recovery from errors, etc.) 



3.2 



Abbreviations 



For the purposes of the present document, the following abbreviations apply: 

2G/3G Second/Third generation mobile services, 

AAA Authentication, Authorization, Accounting 

AuC Authentication Centre 

CAC Call Admission Control 

CDMA Code Division Multiple Access 

CDR Call Detail Records 

CGC Complementary Ground Component 

CWMP Customer premises equipment WAN Management Protocol 

DAMA Dynamic Assignment Multiple Access 

DVB-H Digital Video Broadcasting, services to Handhelds 

DVB-SH Digital Video Broadcasting, Satellites services to Handhelds 

EIRP Equivalent Isotropic Radiated Power 

ESDR ETSI Satellite Digital Radio 

ESG Electronic Service Guide 

ETSI European Telecommunication Standards Institute 

FLUTE File Delivery Over Unidirectional Transport 

FTP File Transfer Protocol 

FUS Firmware Update System 

FWD Forward (link) 

GEO Geostationary Earth Orbit 

GHz Giga Hertz 

GNSS Global Navigation Satellite System 

GPS Global Positioning System 

GSM Global System for Mobile Communications 

GW Gateway 

HLR Home Location Register 

HTTP Hypertext Transfer Protocol 

IC Interference Cancellation/Interleaver Cycle 

ID Identifier 

IETF Internet Engineering Task Force 

IKE Internet Key Exchange 

IMSI International Mobile Subscriber Identity 

IP Internet Protocol 

IPSec IP Security 

IPv4 Internet Protocol version 4 

IPv6 Internet Protocol version 6 

IS Interface Satellite 

ISDN Integrated Services Digital Network 

ITSP Internet Telephony Service Provider 

lU Interleaver Unit/Interface User 

LAN Local Area Network 
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MMS Multimedia Message Service 

MPEG Moving Pictures Experts Group 

MPEG-TS MPEG Transport Stream 

MSS Mobile Satellite Services 

NCC Network Control Centre/Non-Compressed Channel 

NRT Non-Real-time 

OBU On-Board Unit 

PEP Performance Enhancement Proxy 

PHY Physical Layer 

PID Program Identifier 

PSI/SI Program Specific Information/Service Information 

PSTN Public Switched telephone Network 

QoS Quality of Service 

QS-CDMA Quasi Synchronous CDMA 

R&TTE Radio and Telecommunications Terminal Equipment 

RE Radio Erequency 

REC Request for Comment 

RMS Remote Management System 

RT Real-time 

RTCP Real-Time Control Protocol 

RTN Return (link) 

RTP Real-time Protocol 

SDR Satellite Digital Radio 

SEL Service Enabling Layer 

SEP Service Enabling Platform 

SEN Single Erequency Network 

SIP Session Initiation Protocol 

SLR SEP Location Register 

S-MIM S-band Mobile Interactive Multimedia 

SMP S-MIM Messaging Protocol 

SMS Short Message Service 

SNMP Simple Network Management Protocol 

SOAP Simple Object Access Protocol 

SS Subsystem 

551 Service Segment 1 

552 Service Segment 2 

553 Service Segment 3 
SSA Spread Spectrum Aloha 

SSMx Server Side Middleware for Service Segment x 

TCP Transmission Control Protocol 

UDP User Datagram Protocol 

UMTS Universal Mobile Telecommunications System 

USIM Universal Subscriber Identity Module 

VLR Visitor Location Register 

VoIP Voice over IP 

WAN Wide Area Network 



System Overview 



4.1 



General 



An integrated satellite/terrestrial mobile system is described in the present document that provides interactive 
broadcast/multicast, data acquisition and two-way real-time services to subscribers. The S-band payload of a GEO 
satellite is assumed to provide communication links to users; however, non-GEO satellites are also compatible with this 
integrated system provided that Doppler pre-compensation countermeasures are put in place. Eigure 4.1 shows an 
example of the system configuration. 

NOTE: Satellites with payloads that are "transparent" to communication protocols (rather than "regenerative") are 
assumed throughout the present document. 
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On the forward link, a broadcast radio access interface shall be used according to the requirements specified in 
TS 102 721-2 [1]. 

On the return link, the radio interface is based on two non-exclusive options depending on the service required: 

1) Asynchronous access using Spread Spectrum Aloha (SSA) random access. 

2) Synchronous access using Quasi-synchronous Code Division Multiple Access (QS-CDMA) [i.2]. 

A number of terminals with different capabilities are foreseen to enable users to access different sets of services. Access 
to services may be complemented by terrestrial Complementary Ground Components (CGCs). 

Ku-band feeder links are shown as examples of feeder links to the satellite S-band payload and the CGCs. In general the 
feeder links to the S-band satellite payload and the CGCs are independent, i.e. the same feeder link can be used, but also 
different feeder links can be used, even in different frequency bands. Furthermore, the CGC feeder link can also be 
implemented by terrestrial networks. 

Although not shown in Figure 4.1, interconnection with 2G/3G and IP networks is also foreseen to extend the access of 
the user devices to services. 




IP 
^ ^ 



Service Platfbfm 
Environment 



Comiplementary 
Ground 



3-Band CGC 
Forward and Return 



Oyldoor 




Figure 4.1 : S-MIM System Elements 



4.2 User Services of the S-MIM System 

The S-MIM system provides three sets of user services: Service Segments 1, 2 & 3 (SSI, SS2, SS3), which can be 
provided concurrently and in different combinations. 

Each Service Segment is defined by the inclusion of a number of services and service components each with similarities 
in their use of FWD and RTN links and in their QoS. Table 4.1 indicates the list of services that can be provided 
through S-MIM and their classification in terms of Service Segments. 
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Table 4.1 : S-MIM Service Segments 



Service Segment 1 - Broadcast and Interactive Services 


Service 


Service Components 


One-way broadcast/multicast services 


Streaming 


Data distribution 


Interactive broadcast/multicast services 


Interactive streaming 


PayPerView 


Televoting 


Home-shopping 


Interactive data distribution 


PayPerUse 


Content repair 


Service Segment 2 - Data Acquisition Services 


Service 


Service Components 


IVIessaging services 


Vehicle telemetric 


Environmental Monitoring 


IVIessaging Services in Combination with 
GNSS Applications 


Anti-theft Services 


Traffic Monitoring 


Automatic Toll Payment 


Distress Beacon 


Interactive Distress Beacon 


SMS 


- 


Service Segment 3 - Real-Time (Emergency) Services 


Service 


Service Components 


Public safety and emergency services 


eCall 


Two-way IP connection 


Broadcast of Common Interest Messages 


Broadband for Professional Use 


DSL-like connectivity 



4.3 Mapping of Service Segments to Radio Interfaces 

Given the different performance requirements of the services between SSs, the S-MIM system is designed so that in 
each SS the transport of a service is mapped into a suitable specific radio interface. The mapping of services into radio 
interfaces in the FWD and RTN links is shown in Figure 4.2, where two types of radio interface are shown in each case. 

Accordingly, different configurations of the S-MIM system in terms of its FWD and RTN links will support one or 
several of the Service Segments indicated in clause 4.2. 

FWD link capacity is shared between two profiles; a real-time (RT) profile and a non-real-time (NRT) profile. Flexible 
assignment between RT and NRT will allow most of the services to be offered when the RT profile is not available, 
although with (reduced) QoS guarantees of the NRT profile. 

An overview of preferred and mandatory mappings of services into Forward Link Physical Layer Channels is shown in 
Annex A. 
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FWD LINK 



Non-Real Time Physical Channel 
nrt-PCH 



Real Time Physical Channel 
rt-PCH 




Two-way 
Real Time 



SSA 



QS-CDMA 



RTN LINKS 



Figure 4.2: Mapping of Service Segments into available radio interfaces 



4.4 



Terminal Classes 



The S-MIM terminal classes related to Service Segments, etc. are defined in Table 4.2. Further details, including the 
differences between Bx terminals, are available in Table 6.1. 

Table 4.2: Overview of S-MIM Terminal Classes 



Terminal Class 


Name 


Service segments 


Mobility 


A 


Handheld 


1,2 


Mobile 


BO 


Vehicular 


1,2 


Mobile 


B1 


2 


82 


1,2 


B3 


1, 2, 3 (see note) 


C 


Specific 


1,2,3 (see note) 


High speed 


D 


Emergency 


3 


Nomadic 


E 


Fixed 


3 


Fixed 


F 


Sensor 


2 


Fixed 


NOTE: Access to eCall service only, excluding all other SS3 services. 
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S-MIM Network Architecture 



The S-MIM Network Architecture is a structured representation of the general S-MIM system introduced in clause 4.1, 
and is described in terms of its overall segments and interfaces. 

The S-MIM Network Architecture as shown in Figure 5.1 is intended to be a modular system; some elements are 
mandatory for all configurations of the network, while others are optional and can be deployed incrementally to 
increase the performance and the service scope of the system, as described in Annex B. This figure also shows the 
boundaries of the S-MIM system including internal and external interfaces. 



User Segment 



Complementary 
Ground Segment 



S-MIM System 

Satellite Segment 



Ground Segment 



-[IUi]- 

-[IU2]- 



-[IU3]- 



[IU2] 
[IU4] 



r^ — I 

r 



T 



<~[IS5]- 




Servlce Segment 



2G/3G/IP 
Terrestrial Network 



















Service 
Enabling 
Platform 





















Figure 5.1 : S-MIM Network Architecture - Network elements, interfaces and external segments 

The Segments and the Interfaces shown above are described below. 

Configurations of the above network architecture adapted to specific Service Segments are described in Annex B. 

5.1 S-MIM Segments 

The S-MIM system is composed of segments as follows: 

1) User Segment: comprises all types of S-MIM user terminals. 

2) Complementary Ground Segment: comprises CGCs that provide enhanced terrestrial coverage and capacity. 
The two types of CGCs are: 

Forward CGCs (Repeater) repeat the satellite signal in the forward link. They are mainly used to 
complement the coverage area of the satellite in shadowed areas (e.g. urban areas) for the forward link 
signal. Repeaters can also be used to increase the local capacity of the network in the forward direction 
by broadcasting local/regional content not broadcast from the satellite. 
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Return's CGC (Collector) "collect" return link transmissions from terminals and forward them towards 
the ground segment. Collectors can be used to increase coverage in areas where line-of-sight with 
satellite is limited. Collectors shall be co-located with repeaters in order to allow signalling in the 
forward downlink to announce the existence of the collector and its access configuration to the terminals 
in their coverage area. 

3) Satellite Segment: composed of one or several satellites with S-band payloads. Additionally, one or more C, 
Ku or Ka-band satellites may also act as feeder links for the CGCs, although IP-based terrestrial networks 
could also be used. 

NOTE 1 : Specification of the satellite segment is out of scope of S-MIM. 

4) Ground Segment: comprises one or several hubs and the NCC. 

The Hub manages transmissions in the forward and return satellite links, as well as in the forward and 
return CGCs, and subscribers at system level. It also interfaces with the service centres and other 
networks (2G/3G, IP). A hub manages one or more satellite beams; in general, one hub per satellite beam 
can be assumed. 

The NCC is a "master" Hub with additional functionalities to manage configurations and policies of 
other hubs. The NCC is also responsible for satellite configuration management (out of scope of 
S-MIM). 

5) Service Segment: comprises service-enabling functions. 

NOTE 2: The specification of the Service Segment is out of scope of the S-MIM system. 
Within each segment, the component elements are shown in Figure 5.1 and described in clause 6. 
The interfaces between Segments and between S-MIM and external networks are summarized below. 

5.2 S-MIM Interfaces 

The system uses a number of interfaces (numbered from 1 to 7) between system elements for the terminals to 
communicate (through the satellite and the CGCs) with the ground segment. The interfaces indicated in Figure 5.1 are 
listed below: 

Internal Interfaces: 

• Interface {lUl } : minimum interface (user) forward link (with broadcast capabilities); 

• Interface {IU2}: interface (user) forward link with broadcast capabilities and real-time access; 

NOTE 1: Interfaces {lUl } and {IU2} are mutually exclusive in the same satellite payload: interface {IU2} is an 
upgrade of interface {lUl}. Different satellite payloads should support any of the two interfaces 
independently. 

NOTE 2: Interface {IU2} has in fact two possible physical sub-interfaces: the non-real-time profile {IU2a} and the 
real-time profile { IU2b } . 

• Interface {IU3}: interface (user) return link with asynchronous access (SSA); 

• Interface {IU4}: interface (user) return link with synchronous access (QS-CDMA); 
Interfaces to external elements: 

NOTE 3: These interfaces are out of scope of the S-MIM specification. 

• Interface {IS5}: interface (satellite) - between satellite and CGC (to be specified by the satellite operator e.g. 
Ku-band or other); 

• Interface {16}: generic IP interface, including communication with end-user devices; 

• Interface {IS7}: interface (satellite) - between satellite and Hub intended for traffic to user terminals (to be 
specified by the satellite operator e.g. Ku-band or other); 
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• Interface {IS8}: interface (satellite) - between satellite and Hub, intended for traffic to CGC's (to be specified 
by the satellite operator e.g. Ku-band or other). 

6 Network Elements 

This clause describes the S-MIM network elements in terms of: 

• The User Terminals. 

• The Network Control Centre and the Satellite Hub. 

• The Complementary Ground Components. 

6.1 The User Terminals 

The S-MIM system includes several user terminal classes with different capabilities in terms of performance, mobility 
and accessible Service Segments, requiring different access technology and service-specific functions. Terminal 
characteristics are defined in Table 6.1. 

For all these terminals, specific requirements for the Forward Link Subsystem, Return Link Asynchronous/ 
Synchronous Access, Link Layer and Control Plane apply and are given respectively in Parts 2 [1], 3 [i.9], 4 [i.lO], 
5 [i.ll] and 6 [i.l3] of this multi-parts deliverable. 

6.1 .1 Terminals with Access to SS1 and/or SS2 

Terminals A, BO, Bl, B2, B3, C and F can access SSI and SS2. The baseline configuration of these terminals is shown 
in Figure 6.1. 

Such terminals shall be equipped with radio interfaces to access SSI and SS2 services in the FWD and RTN links, as 
per TS 102 721-2 [1]. The terminals may be equipped with a GPS receiver or other positioning device (e.g. any GNSS 
receiver, GSM/UMTS phone, or even WiFi enabled terminal) to assist the S-MIM control plane to perform mobility 
management. 

Terminal B3 is similar to B1/B2 terminals but with additional access as described in clause 6.1.2 (to the eCall service 
which belongs to SS3 and can only be accessed if the QS-CDMA radio access is also available at the terminal). 
Therefore, the complete functional description of terminal B3 is achieved by merging Figure 6.1 with Figure 6.3 (except 
the features related to terminals D and E only). 

6.1 .1 .1 The Type C Terminal 

Terminal C is a special case of SSl/2 terminal (see Figure 6.2) and its scope is twofold: 

1) it shall be capable of transmitting and receiving in the S-band (as for terminals A, Bx and F), but with higher 
speed mobility; 

2) it shall act as gap filler to allow other devices to access the S-band services in a vehicle (for example train or 
aircraft). 

Therefore the terminal C is similar to terminals A, Bx and F, but the application layer within the user device should only 
contain network management functions, as the user data will be directly routed by the IP layer router at the IP Suite SS 
towards the IP SS (with 802. llx or Ethernet access). 

The IP traffic received from the IP SS through its uplink will be routed by the IP router at the IP Suite SS towards the 
S-Band SS Link layer to encapsulate it according to the S-band SS waveform and transmit it over the S-band radio 
interface (SSA in this case). 

For the eCall service option, the functionalities shall be extended to include QS-CDMA radio interface, link layer (user 
and control planes) and the indicated functions for C terminals in Figure 6.3 in IP and application layers. 
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6.1 .2 Terminals with Access to SS3 

Terminals B3, C, D and E access SS3 services. A functional diagram of their architecture is shown in Figure 6.3. 

As a part of service-enabling platform, SS3 compliant terminals shall have functional elements which are part of the 
0SM3 (OBU Side Middleware), to enable users to perform or receive VoIP calls and to access data information located 
on Intranets or Internet. 
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Table 6.1 : S-MIM Terminal classes 



Terminal Class 


A 


BO 1 B1 1 B2 1 B3 


C 


D 


E 


F 


Name 


Handheld 


Vehicular 


Specific 


Emergency 


Fixed 


Sensor 


Service segments 


1,2 


1,2 |2 |1,2 |1,2, 3(note1) 


1,2, 3 (note 1) 


3 


3 (note2) 


2 


Mobility 


Mobile 


Mobile 


High speed 


Nomadic 


Fixed 


Fixed 


Supported bit rate 
(FWD/RTN) 


Medium/Low 


Medium/Low 


Low/Medium 


Medium/ 
Medium 


Medium/ 
Medium 


High/High 


High/High 


High/High 


Low/Medium 


Power Class (note 4) 


Ibis 


Ibis 


Ibis 


Ibis 


1 


1 


1 


1 


Ibis 


Tolerance (note 5) 


+1/-3dB 


+1/-3dB 


+1/-3dB 


+1/-3dB 


+2,7/-2,7 dB 


+2,7/-2,7 dB 


+2,7/-2,7 dB 


+2,7/-2,7 dB 


+1/-3dB 


Nominal EIRP 


2dBW 


2dBW 


5dBW 


5dBW 


11 dBW 


15 dBW 


15 dBW 


15 dBW 


5 dBW 


Antenna performance 
(G/T) (note 3) 


Low 
-29 dB/K 


Low 

-25 dB/K to 

-24 dB/K 


Medium 
-21 dB/K 


High 
>-21dB/K 


High 
>-21dB/K 


High 
>-21dB/K 


Medium 
-21 dB/K 


















Access to CGCs 


Yes 


Yes 


Yes 


Yes 


No 


No 


Yes 


Power supply 


Battery 


Battery 


Power supply from vehicle 


Power supply from 
vehicle 


Power supply from 
vehicle or portable 
generator 


Local power 
network or 
power units 


Local power 
network, power 
units or batteries 


Other details 


Consumer 
Terminal 


Consumer 
Terminal 


Terminal embedded in vehicle 


Collective 
Terminal installed 
in fast moving 
vehicle 


Professional 
(collective) Terminal 
for emergency 
operators 


Collective 
terminal 
Size of typical 
set-top-box 


Sensor network 
terminal 


NOTE 1 : eCall only. 

NOTE 2: No emergency services, only broadband access. 

NOTE 3: Handheld terminals belong to category 2b in [i.1]; vehicular terminals to category 1 ; nomadic and fixed terminal having at least the G/T performance of category 1 or better, 

assuming the antenna is constantly pointed towards the satellite. 
NOTE 4: Power Classes are compliant with [i.4]. 
NOTE 5: Tolerance refers to the maximum output power as in [i.4] and not to the accuracy in setting the actual output power. 
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Figure 6.1 : Functional diagram of the SS1/SS2 user terminal 
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Figure 6.2: Functional diagram of the user terminal - Type C with access to SS1/SS2 only 
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Figure 6.3: Functional diagram of the SS3 user terminal 
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6.2 



The Network Control Centre and the Satellite Hub 



The Network Control Centre (NCC) manages the complete S-MIM network. However, the management of the complete 
S-MIM network may be distributed, considering that within each service area a different set of services may be offered. 
With a distributed approach, the NCC functions to manage transmission/reception will be distributed in satellite hubs. 
In particular, a satellite hub manages one service area; a service area refers to the geographical area covered by one or 
several satellite beams. Therefore, the hub managing one service area in practice manages transmissions (in FWD and 
RTN links) through the corresponding satellite beam(s) and the CGCs located within the coverage area of that (or those) 
satellite beam(s). 

Depending on the satellite operator requirements, two possible options are considered for the topology of the hubs 
network, as can be seen in Figure 6.4: 

• Fully meshed hub network: all hubs are interconnected. 

• Hierarchical meshed topology: all hubs are interconnected, while one hub has additional functionalities to 
manage the rest of hubs. This hub with network wide management functionalities will be called Network 
Control Centre (NCC). 

In the meshed topology, each hub manages independently its service area (beam or set of beams); hubs are 
interconnected for routing purposes and mobility management (especially for the support of roaming); one of the hubs 
has also Network Control Centre functionalities, referring to the management of the S-band satellite. In the hierarchical 
topology, the NCC has the role of a "master hub" that, in addition to the hub functionalities and the management of the 
satellite, can manage specific aspects of the rest of hub's operation. 

The functional description of the regular hub in the meshed topology or all hubs other than the NCC in the hierarchical 
meshed topology is provided in clause 6.2.1; the additional functionalities to be fulfilled by the NCC (or master hub) of 
the hierarchical meshed topology is provided in clause 6.2.2. 



MESHED TOPOLOGY 



HIERARCHICAL MESHED TOPOLOGY 



I— HUB 2 




HUB 1 / NCC 



,- HUB 2 



HUB 3 



HUB 4 



Figure 6.4: NCC/Hub network topologies 

6.2.1 The Satellite Hub 

The hub implements a number of subsystems and functions as shown in Figure 6.5, and as described in Table 6.2. 

The functional description of the hub corresponds to any of the hubs in the meshed topology or all hubs other than the 
NCC in the hierarchical meshed topology. In the particular case of the meshed topology, the hub operates independently 
of other hubs, and hence all local configurations and decision policies (called NCC policies in Figure 6.5) are generated 
and managed locally. In the case of the hierarchical meshed topology, the hub is interconnected to a master hub (or 
NCC) which manages the configuration of each hub and generates the NCC decision policies to be implemented in the 
hub through network management protocols. 
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Figure 6.5: Functional diagram of tlie satellite hub 
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Table 6.2: Functional description of the satellite Hub 



User Plane 


S-band FWD SS 


This subsystem implements the radio interface in the S-band FWD link. It implements all 
functions necessary to encapsulate, apply header compression (optional), encryption 
(optional), filter content, modulate and transmit data in the S-band FWD link; 
After encapsulating, the S-band FWD SS shall differentiate the content (multiplex) that has to 
be sent through the satellite from the content (multiplex) that has to be sent through the 
CGCs; in particular, the CGC multiplex is a repetition of part of the satellite multiplex; 
additionally, the CGC multiplex may contain local contents not transmitted over the satellite. 
Figure 6.5 shows the particular case that DVB-SH is the radio interface applied in S-band 
Subsystem. 


Gateway Feeder 
Link RTN 
SSASS 


The SSA radio interface is used for asynchronous access in the S-band RTN link. It 
implements all functions necessary to demodulate, decapsulate data; note that the 
decapsulator may include decryption and header decompression capabilities. Advanced 
signal processing allowing efficient IC in packet mode (such as SSA) is strongly 
recommended to increase system throughput particularly in the presence of power imbalance. 
The deployment of this subsystem is only required in the hub if the hub manages one or 
several service areas where the deployed services require asynchronous access in the RTN 
link. 


Gateway Feeder 
Link RTN 
QS-CDMA SS 


The QS-CDMA radio interface is used for synchronous access in the S-band RTN link. It 
implements all functions necessary to demodulate and decapsulate data; note that the 
decapsulator may include decryption and header decompression capabilities. It also provides 
the functions necessary to monitor terminal synchronization and power imbalances and 
compute the appropriate corrections to be forwarded to the terminal. 
The deployment of this subsystem is only required in the hub if the hub manages one or 
several service areas where the deployed services require synchronous access in the RTN 
link to support real-time bidirectional services. 


CGC gateway 
feeder link FWD SS 


This subsystem acts as the baseline feeder link for the FWD CGCs. It receives a prepared 
transport stream from the FWD Encapsulator (managed by the content manager) which it 
re-encapsulates into the Ku-band FWD SS radio interface (see notes 1 and 2). 


CGC gateway 
feeder link RTN SS 


This subsystem acts as the baseline backhauling facility for the RTN CGCs. It demodulates 
and decapsulates (and decrypts) the received signal through the RTN link Ku-band radio 
interface and delivers SSA frames to the SSA Decapsulator (see note 3). 


FWD CGC IP 
Tunnel SS 


This subsystem acts as the alternative feeder link for the FWD CGCs. It receives a prepared 
transport stream from the FWD Link Layer SS (managed by the content manager) which it 
encapsulates into a secure IP tunnel and transmits it through an IP connection towards the 
CGCs. 


RTN CGC IP Tunnel 
SS 


This subsystem acts as the alternative backhauling facility for the RTN CGCs. It decapsulates 
the secure IP tunnel established with the RTN CGCs and delivers SSA frames to the SSA 
Decapsulator. 


IP router 


It routes the input IP packets (coming from the SSA and the QS-CDMA Decapsulators) 
towards the relevant Service Enabling Platform, Bidirectional Service Gateway or Broadcast 
Content Provider. 
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Control Plane 



Signalling Manager 



This functional block manages the system specific signalling. In particular, the following 
functions are implemented by the signalling manager: 

• Negotiation of security standard to be used in the FWD link (in satellite AND CGC 
access) for communication with a user terminal; informing the Encapsulator at the 
S-band SS about the layer at which encryption shall be performed for a specific flow 
in each link; manage signalling for IPSec security associations in the FWD link. 

• Management of acknowledgements for the satellite link. 

• Management of acknowledgements for the CGC links. 

• Collection of signalling from other functions of the control plane and forwarding of 
signalling coming from the RTN link to the right control plane function. 

• Assembly of signalling tables for the satellite link and for the terrestrial links and 
forwarding to the signalling buffers towards the FWD Encapsulator. 

• To collect and store information from the S-band RTN SSA SS and the S-band RTN 
QS-CDMA SS about network activity monitoring (network access level CDRs). In 
particular, for the S-band RTN SSA SS, at least the following records shall be kept 
for each received packet: origin, destination, volume of data, time stamp. For the 
S-band RTN QS-CDMA SS, the CAC/DAMA can collect channel setup and clear 

time-stamps, RTN link spot ID, clear reason or allocated BW. 



Resource and 
Mobility Manager 



This functional block has two main sub-functions: the Resource Management and the Mobility 
Management sub-functions. 

• Resource management sub-function. This sub-function manages the resource 
allocation in FWD and RTN links. It is composed of the following modules and 
functionalities: 

FWD SS1/SS2 Module: composed by the FWD Link Capacity Manager and the NCC 
policies applicable to SS1/SS2. 

The FWD Link Capacity Manager manages the data flows for efficient sharing of 
FWD link resources among flows, for the satellite and for the CGC links. It fulfils the 
following tasks: 

Negotiate and stores the QoS guarantees of each flow with the interface of the 

Service Providers to the Hub. 

Monitor the QoS performance of each flow. 

Instruct the multiplexer in the Encapsulator about the structure of the output 

transport stream: 

- to be transmitted over the satellite; 

- to be transmitted over the CGCs. 

packet scheduling, profile selection (RT vs. NRT), capacity share (between RT 
and NRT profiles) resizing and multiplexing. 

• RTN SS1/SS2 Module: composed by the RTN load control manager: 

The RTN load control manager: 

- monitors (i) the load in the satellite RTN link radio interfaces and (ii) 
the load in the CGC RTN link radio interfaces; 

- performs load control (i) in the satellite link and (ii) in the CGC links, 
independently. This functionality is only required at the hub if the services 
deployed in the managed service area require asynchronous access in the 
RTN link. 

• SS3 Module: composed by the CAC/DAMA manager: 

The CAC/DAMA Manager: it monitors the load in the RTN link synchronous 
radio interface in the satellite link and performs capacity request/assignment 
management. This functionality is only required at the hub if the services 
deployed in the managed service area require synchronous access in the RTN 
link to support bidirectional real-time applications. 
Mobility Management sub-function: this sub-function includes functionalities to provide 
services to the users of the S-MIM system in all service areas. Consequently, the following 
functionalities are enclosed: 

• Terminal location management; 

• Handover management; 

• Roaming management. 



Content Manager 



(see note 4) 

This function manages the content in the satellite and terrestrial FWD link multiplexes. In 

particular, the following functionalities shall be implemented: 

• Prepare the multiplex to be feed to the satellite S-band payload and to the CGCs 
with global and local content through the relevant feeder link and align the global 
content with the satellite global content. 
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Control Plane 



Encapsulator/ 
Decapsulator 
Controller 



This element implements control functions for the Link Layer protocols implemented in the 
encapsulator/decapsulator: 

Management of header compression context and forwarding of related signal to the 

signalling management for the FWD link. 

Management of header compression context and forwarding of related signal to the 

signalling management for the asynchronous RTN link. 

Negotiation of bidirectional header compression for synchronous RTN link and 

related traffic in the FWD link. 

Mutual authentication according to Link Layer Security option. 

Mutual authentication according to IPSec option. 



HLR/VLR 



These are databases containing user location and profile information. 

The HLR is a database that contains details of each S-MIM subscriber that is authorized to 

access the S-MIM system. 

The HLRs store details of every USIM issued by the S-MIM operator: 

• The IMSI (unique identifier of the subscriber, which is the primary key to each HLR 
record). 

• S-MIM services that the subscriber has requested or been authorized to use with its 
contract. 

• Current location of subscriber (i.e. visited VLR and serving hub in case of roaming). 
Its main functions are: 

• To support the mobility management function by updating the current location area 
applicable to the subscriber. 

• To send the subscriber data to the VLR of a visited hub when a subscriber first 
roams there. 

• To remove subscriber data from the previous VLR when a subscriber has roamed 
away from it. 

• The VLR is a temporary database of the subscribers who have roamed into the 
particular service area which it serves. The enclosed information is acquired either 
from the home HLR of the subscriber. The stored data is the following: the IMSI, the 
phone number, the authentication data, the list of services the subscriber is 
authorized to access, the home hub and HLR of the subscriber. 



Authentication 
Centre (AuC) 



The AuC is a function to generate authentication vectors that are used during the procedures 
to authenticate each subscriber that attempts to access the S-MIM system. It also stores 
shared secret data between the USIM and the AuC to verify identities and to generate 
encryption keys once a security association is achieved among the subscriber and hub. 



Management Plane 



This function includes the following sub-functions: 
Terminal management. 
Network management. 
User traffic monitoring. 



The Network 
Manager 



NOTE 1 : 
NOTE 2: 



NOTE 3: 



NOTE 4: 



The radio interface implemented by the Ku (or other) -band FWD link SS is out of scope of S-MIM. 

In the case that the Ku-band and S-band SS's have independent PID assignment to services and 

programmes, the Ku-band FWD SS shall include an MPEG-TS encapsulator, as the S-band services shall 

be then re-encapsulated in MPEG-TS with the PID association related to the Ku-band SS. 

The radio interface implemented by the Ku-band RTN link SS is out of scope of S-MIM. However, 

DVB-RCS is assumed as baseline radio interface. 

This module is implementation dependent and will not be specified within the S-MIM system. 



6.2.2 The Network Control Centre 

The NCC manages configurations and policies of the S-MIM network as well as the satellite management (the satellite 
management aspects are out of scope of the S-MIM system). However, the NCC may also manage the local 
configuration of each hub and determine decision policies that shall be common (or not) to all hubs. 

In particular, the additional NCC functionalities, excluding the satellite management issues, consist of: 

• the capability of remotely configure other hubs parameters (e.g. decision policies, thresholds, managing 
addressing spaces, etc.) through network management protocols; 

• keeping overall network list of subscribers and configurations (HLRA^LR), numbering resources; 

• overall network usage and performance monitoring; 
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• provide a common interface for sending SIP signalling from the ground segment. Although, this interface may 
be implemented in a master hub, see Figure 6.4. 

The satellite operator may map each of the Management Plane functions in a distributed (throughout the hubs) or 
centralized manner (into the NCC) according to its preferences. 

6.3 The Complementary Ground Components 

FWD CGCs (Repeaters) and RTN CGCs (Collectors) are interrelated; repeaters are stand-alone ground elements 
managed by the hub, while collectors shall be co-located with repeaters to allow the broadcast of relevant signalling in 
the FWD link required by the terminal to configure correctly the transmission parameters to be used in the RTN link. 

Specific features of repeaters and collectors are detailed in the following clauses. 

6.3.1 TheFWDGGO 

A number of FWD CGCs provide coverage to a common geographical area where the same set of local content is 
provided, shall operate in SFN among Repeaters. A Set of CGCs operating in SFN, that provide service to a common 
geographical area, will be called CGC Cluster. 

The FWD CGC offers up to four different external interfaces, some of them being exclusive in a CGC cluster (in other 
words, in a CGC cluster, all CGCs shall support the same FWD air interface): 

• {lUi} or {IU2} towards the user terminals; and 

• {IS5} (Ku-band or other satellite feeder link frequencies) and/or {l^} (an IP connection) to receive the content 
that has to be repeated towards the user terminals though the {lUi} or {IU2} interface. 

In the case that DVB-SH is applied as {lUl } or {IU2}, respectively, the following applies: 

Figure 6.6 shows the functional diagram of the Repeater. The functionalities to be fulfilled by each functional block are 
listed in Table 6.3, classified in User, Control and Management planes. Note that the Control and Management planes 
refer to the S-band SS only. 
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Table 6.3: Functional description of the FWD CGC 



User Plane 


S-band CGC Tx SS 


The following functions are fulfilled by this functional block: 

• To demultiplex the received transport streams to differentiate contents. In 
particular, signalling to the CGC, global content and different local contents 
relevant to different CGC Clusters shall be differentiated. 

• To decapsulate signalling information for remote management of the FWD CGC 
(network management). 

• To remove content not meant for the CGC cluster this CGC belongs to. 

• To feed the relevant content (RT if available and NRT content) to the modulator. 

• To perform modulation according to {IU1} or {IU2} interface (depending on the 
deployed technology). 

• Transmit the signal from the CGC at S-band. 


Gateway to CGC 
forward feeder link. 
SS 


The Gateway to CGC forward feeder link SS is the baseline feeder link to the FWD CGCs 

(see note 1). 

The signal received at the Gateway to CGC forward feeder link SS transports the pre- 

configured global and local multiplexes. The Gateway to CGC forward feeder link SS shall 

receive the Ku-band signal and demodulate it (see note 2). 

The outputs of the Gateway to CGC forward feeder link SS are the pre-configured global 

and local multiplexes in MPEG-TS format. 


IP CGC feed SS 


The IP CGC feed SS is the alternative feeder link to the FWD CGCs. The physical input 
interface can be wired or wireless. 

The IP SS manages an (secure) IP tunnel between the Repeater and the serving hub. It has 
as input an IP stream that transports the pre-configured global and local multiplexes in 
MPEG-TS format. The IP SS shall receive the input IP signal and decapsulate (undo the IP 
tunnel) it to output one or several MPEG-TS streams. 


Control Plane 


N/A 


All Control Plane functions related to the CGC are fulfilled in its managing hub. The CGC 
simply repeats the signal received through its feeder link and removes useless content in the 
corresponding SFN area. 


Management Plane 


S-band SS 


Within the S-band SS, the following control plane functions shall be included: 
Network Management: this function receives remote management commands from its 
managing hub or NCC to allow remote configuration and control of sub-systems 


NOTE 1 : The Gateway to CGC forward feeder link SS specification is out of scope of the S-MIM system. 

NOTE 2: In the case that the Gateway to CGC forward feeder link SS and the S-band SS have independent PID 
assignment to services and programmes, the Ku-bands SS shall include an MPEG-TS decapsulator, as 
the S-band services shall be then re-encapsulated in MPEG-TS with the PID association related to the 
Gateway to CGC forward feeder link SS. 



6.3.2 The RTN CGC 

The RTN CGC shall be co-located with a Repeater to allow the broadcast of local signalling of the Collector. Figure 6.7 
shows the functional diagram of the Collector completing the functional block of the Repeater to allow also access in to 
RTN link services. 

Additionally to the FWD link-related interfaces, the Collector presents additional external interfaces: 

• {IU3 } (SSA) from the user terminals; and 

• {IS5} (Ku-band - or other - RTN satellite link) and/or {l^} (an IP connection) for backhauling of received data 
from the user terminals towards the hub. 

Figure 6.7 shows the functional diagram of the Collector, including those of the co-located Repeater. The functionalities 
to be fulfilled by each functional block are listed in Table 6.4 classified in User, Control and Management planes. 
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Table 6.4: Functional description of the RTN CGC 



User Plane 


S-band CGC Rx SS 


Additionally to the Repeater-specific functional blocks, the following functionalities shall be 
fulfilled by the Collector S-band RTN SS: 

• Receive and demodulate the SSA input signal. 

• Feed the output SSA frames into the CGC to GW return feeder link SS 
encapsulator (or into the IP network SS encapsulator). 


CGC to GW return 
feeder link SS 


The CGC to GW return feeder link SS is the baseline backhauling link to the RTN CGCs 
(see note 1). 

Additionally to the Repeater-specific functionalities, the following functions shall be fulfilled 
by the CGC to GW return feeder link SS: 

• Encapsulate the input SSA frames in the data format of the CGC to GW return 
feeder link SS. 

• To monitor the input buffer and generate capacity requests to cope with the input 
traffic (see note 2). 

• To interpret and apply the capacity allocations signalled by the managing hub of 
the CGC through the satellite feeder link (and demodulated at the feeder FWD SS. 

• To modulate the backhauling signal. 

• To transmit the backhauling signal (for example in Ku-band). 


IP CGC feed SS 


The IP CGC feed SS is the alternative backhauling link in the RTN CGCs. The physical 
output interface can be wired or wireless. Additionally to the Repeater-specific 
functionalities, the following functions shall be fulfilled by the IP CGC feed SS in the RTN 
link: 

• to create and maintain an (secure) IP tunnel between the RTN CGC and the 
serving hub to backhaul the received SSA frames through the S-band RTN SS. 


Control Plane 


N/A 


All Control Plane functions related to the CGC are fulfilled in its managing hub. The CGC 
simply repeats the signal received through its feeder link and removes useless content in the 
corresponding SFN area. 


Management Plane 


S-band SS 


Network Management: this function receives remote management commands from its 
managing hub or NCC to allow remote configuration and control of sub-systems. 


NOTE 1 : The CGC to GW return feeder link SS specification is out of scope of the S-MIM system. 

NOTE 2: This is assuming that the backhauling link is a shared link with other CGC to GW feeder RTN SS or other 

services. In the case that a fully dedicated link (SCPC) is allocated to the CGC, the management of 

capacity requests is not required, and in any case out of scope of S-MIM. 
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Figure 6.7: Functional diagram of the RTN CGC 
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7 Protocol Architecture 

Network element functions are divided into three planes: User, Control and Management. 

The following clauses show protocol stacks for combined User and Control planes in the FWD and RTN links. The 
Management Plane is described in Annex D. 

Further details are given in the other parts of this multi-parts deliverable. 



7.1 



Forward Link 



7.1 .1 Forward Link Reference Protocol Stack 

The generalized protocol stack for the Forward link for access to SSI, SS2 and SS3 is depicted in Figure 7.1. 

For SSl/2, the upper layer protocols (referred to as Application & Service Delivery Layer in the figure) correspond to 
the IP Datacast protocols plus an additional delivery protocol to deliver short messages, the S-MIM Messaging Protocol 
(SMP). The SMP has been introduced to optimally deliver short messages over the underlying PHY, as the IP Datacast 
protocols are optimized for the transmission of streaming and data in the form of medium to long files. 

The use of a connectionless Transport Protocol, such as UDP, is strongly recommended to communicate with SSI and 
SS2 user terminals, as all services under such service segments are connectionless as well. 

For SS3 an UDP/IP layer is also considered to provide support to standard VoIP protocols, SIP, RTP and RTCP. 
Additionally, a TCP/IP layer is required to provide support to HTTP, FTP or other protocols that rely on the provision 
of 2- way IP connectivity services in the scope of SS3. 

The Link Layer provides efficient transport of IP user data over the forward link radio interface. 
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Figure 7.1 : Generalized protocol stack for the Forward link 

7.1 .2 Forward Link Protocol Architectures 

Two cases of protocol stack are defined for transport of user data between the Hub and the user terminal: 

1) satellite link only; 

2) satellite and/or the FWD CGC. 
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The blocks marked in yellow are those specific to the S-MIM system. 

7.1.2.1 Satellite Link Only 

Figure 7.2 shows the case in which only the satellite is used. 
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Figure 7.2: Forward Link Protocol Architecture for Satellite Connectivity 

7.1 .2.2 Satellite and/or FWD CGC 

Figure 7.3 shows the end-to-end protocol architecture. Depending on the feeder link selected for the repeater, the 
satellite Hub will need specific interfaces. Two examples are shown in Figure 7.3: (i) the feeder link is a Ku-band air 
interface (e.g. DVB-S2) and (ii) the feeder link is an IP connection. 

In the first case, the link layer at the Hub delivers MPEG transport streams to the Ku-band air interface, which 
transports them transparently. 

NOTE 1 : To allow this transparent transport, the PID services of the S-band system should be known to the 

Ku-band system. If this is not fulfilled, the MPEG-TS from the S-band mission should be re-encapsulated 
into dedicated MPEG-TS of the Ku-band mission. 

The FWD CGC (or repeater) receives the Ku-band waveform, demodulates it and recovers the transported MPEG-TS 
over the Ku-band waveform. Then, the CGC disaggregates the transport stream in its primary streams and removes the 
primary streams that do not correspond to services for the CGC (local content of other SEN clusters) and inserts the 
filtered multiplex into the FWD radio interface modulator of the CGC. 

NOTE 2: The CGC should be capable of differentiating which services it should transmit from those that are not 
meant for this CGC. 

In the second case, an IP tunnel is assumed for feeding the repeaters with content. Therefore, the output data of the link 
layer is re-encapsulated into an IP tunnel in a transparent manner. Consequently, the Repeater shall implement also the 
IP tunnel features in order to recover the MPEG-TS stream provided by the link Layer and feed it to the FWD radio 
interface modulator. 
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Figure 7.3: Forward Link Protocol Architecture for Terrestrial Connectivity 



7.2 



Return Link 



The SSA and QS-CDMA options are described separately below. 

In the baseline configuration, S-MIM synchronous and asynchronous access schemes share the whole bandwidth. 
Alternatively, a 5 MHz RF channel might be split in narrower RF channels that could be dynamically assigned to the 
S-MIM synchronous or asynchronous accesses. In this case, narrower channelization would be used. 

7.2.1 Asynchronous Return Link Reference Protocol Stack 

As per the Forward link protocols, the Internet Protocol (IP) shall be supported in the Return link. Only short messages 
shall be transmitted through the SSA access. Therefore the same protocol as in the FWD link to deliver short messages 
will be applied in the upper layer, as can be observed in Figure 7.4. 
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Figure 7.4: General protocol stack for Asynchronous (SS1/SS2) return link 
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7.2.2 Asynchronous Return Link Protocol Architectures 

Two cases of protocol stack are defined for transport of user data between the Hub and the user terminal: 

1 ) satellite link only ; 

2) satellite and/or the RTN CGC. 

The blocks marked in yellow are those specific of the S-MIM system. 

7.2.2.1 Satellite Link Only 

Figure 7.5 shows the case in which only the satellite is used. 
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SSA 
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Figure 7.5: Asynchronous Return Link Protocol Architecture for Satellite Connectivity 



7.2.2.2 Satellite and/or RTN CGC 

For communications through the RTN CGC, Figure 7.6 shows the S-MIM protocol stack. In this case, the presence of a 
RTN CGC (or Collector) adds some complexity to the protocol stack at the Hub. As it can be observed, depending on 
the backhauling link selected for the Collector, the satellite Hub will need specific interfaces. Two examples are 
depicted in Figure 7.6, namely the cases that the backhauling link is a Ku-band air interface (e.g. DVB-RCS) or an IP 
connection. 

In the first case, the link layer at the Hub delivers SSA frames to the Ku-band air interface, which transports them 
transparently. The Collector just feeds the received SSA frames into the Ku-band Subsystem that encapsulates the SSA 
frames transparently into the data format of the Ku-band radio interface. In the second case, an IP tunnel is assumed for 
backhauling the data received at the Collectors. Therefore, the output data of the SSA demodulator (SSA frames) is 
re-encapsulated into an IP tunnel in a transparent manner. Consequently, the Hub shall implement also the IP tunnel 
features in order to recover the SSA frames and feed them into the link layer at the Hub. 
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Figure 7.6: Asynchronous Return Link Protocol Architecture for Terrestrial Connectivity 

7.2.3 Synchronous Return Link Reference Protocol Stack 

The Internet Protocol (IP) shall be supported in the QS-CDMA RTN Hnk. Through the QS-CDMA access, the 
following services are provided: eCall, VoIP and two-way-IP connectivity. Inline with these requirements, the reference 
protocol stack for the QS-CDMA RTN link in the User Plane for access to SS3 is depicted in Figure 7.7. 
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Figure 7.7: General protocol stack for Synchronous (SS3) return link 

7.2.4 Synchronous Return Link Protocol Architecture 

Unlike the asynchronous access, the synchronous access is only applicable to the satellite link. Services corresponding 
to SS3 are not distributed over the CGCs. Figure 7.8 shows the protocol stack for the S-MIM access in the synchronous 
return link access. 
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Figure 7.8: Synchronous Return Link Protocol Architecture for Satellite Connectivity 



ETSI 



37 



ETSI TS 102 721-1 VI .2.1 (2013-08) 



Annex A (normative): 

Mapping of Services into Forward Link Physical Layer 

Channels 

Table A.1 



Service Segment 


1 - Broadcast and Interactive Services 


NRT Profile | RT Profile 




(M = mandatory, P = preferred) 


One-way 

broadcast/multicast 

services 


Streaming 


M 


- 


Data distribution 


M 


- 


Interactive 

broadcast/multicast 

services 


Interactive streaming 


PayPerView 


- 


P 


Televoting 


- 


P 


Home-shopping 


- 


P 


Interactive data 
distribution 


PayPerUse 


- 


P 


Content repair 


- 


P 


Service Segment 2 - Data Acquisition Services 






IVIessaging services 


Vehicle telemetric 


- 


P 


Environmental Monitoring 


- 


P 


Messaging Services in 

Combination witli GNSS 

Applications 


Anti-theft Services 


- 


P 


Traffic Monitoring 


- 


P 


Automatic Toll Payment 


- 


P 


Distress Beacon 


- 


P 


Interactive Distress Beacon 


- 


P 


SMS 


- 


- 


P 


Service Segment 3 - Real-Time (Emergency) Services 






Public safety and 
emergency services 


eCall 


- 


M 


Two-way IP connection 




M 


Broadcast of Common Interest Messages 


- 


P 


Broadband for 

Professional and 

Consumer Use 






M 


Signalling 






Resource Management 


Load control 

Call Admission Control 

DAMA Assignment 




M 


Operational Signalling 


Local configuration 

ACKs 

AAA/Encryption 

Capacity share resizing (NRT vs. RT) 




P 


Mobility Management 


Authentication messages and system information 
(PSI/SI) are used. Each will use one profile. 


M 


M 


Service Management 


Announcement, association tables, etc. 


M 


- 


Terminal Management 




P 


- 
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Annex B (informative): 

Network Architecture Configurations 

The modular S-MIM network architecture described in clause 5 can be implemented in different configurations (and 
sub-configurations), based on a core set of elements, to suit provision of different Service Segments. 

The complete network architecture including all optional elements and interfaces is shown in Figure B.l. This also 
shows the Core S-MIM Network components necessary for any configuration. 
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Figure B.1 : Complete S-MIM network architecture 

Depending on the configuration, some of the elements of the radio access part of the system shown are not required. 
The main architecture configurations with necessary elements and interfaces are shown in Table B.l. 
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Table B.I : S-MIM Network Architecture Configurations 



Config 


Service 
Segments 


Sub- 
config- 
uration 


Features 


Additional Elements to "Core" 


Associated 
additional 
interfaces 


1 


SS1 
+ SS2 
+ SS3 


1a 


Full S-MIM Deployment 


Terminals A, BO, B1 , 82, B3, C, F 


IU2, IU3 


Terminals B3, C, D, E, 


IU2, IU4 


Forward CGC 


IU2, IS5 (or 16) 


Return CGC 


IU3, IS5 (or 16) 


1b 


Absence of Collector 


Terminals A, BO, B1 , B2, B3, C, F 


IU2, IU3 


Terminal B3, C, D, E 


IU2, IU4 


Forward CGC 


IU2, IS5 (or 16) 


1c 


Absence of Repeaters 


Terminals A, BO, B1 , B2, B3, C, F 


IU2, IU3 


Terminal B3, C, D, E 


IU2, IU4 


Id 

(no SS3) 


FWD link without real time 
capabilities 


Terminals A, BO, B1, B2, B3, C, F 


IU1,IU3 


Forward CGC 


IU1, IS5(orl6) 


Return CGC 


IU3, IS5 (or 16) 


2 


SS2 Only 


2a 


FWD link without real time 
capabilities 


Terminals A, BO, B1 , B2, B3, C, F 


IU1,IU3 


Forward CGC 


IU1, IS5(orl6) 


Return CGC 


IU3, IS5 (or 16) 


2b 


FWD link with real time 
capabilities 


Terminals A, BO, B1 , B2, B3, C, F 


IU2, IU3 


Forward CGC 


IU2, IS5 (or 16) 


Return CGC 


IU3, IS5 (or 16) 


3 


SS3 Only 




Terminals B3, C, D, E, 


IU2, IU4 


4 


SS1 (with no 
interactivity) 
+ SS3 




Terminals A, C 


IU2 


Terminals C, B3, D, E 


IU2, IU4 


Forward CGC 


IU2 IS5 (or 16) 



The configurations detailed above apply to services provided by a single satellite payload and its related CGCs. 
These configurations allow independent network configurations in different satellite beams. 
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Annex C (informative): 

The Service Enabling Platform 



The Hub-side Service Enabling Platform (SEP) and its terminal-side counterpart Service Enabling Layer (SEL) 
middleware interact to provide users with access to any SS supported by the class of terminal employed. This 
intermediate platform is the transaction gateway of all service segments between the end users and the corresponding 
Service Providers. 

The aim of the S-MIM network is not to impose a particular technology for any particular service segment, but to 
employ standard protocols such as SIP for VoIP and eCall SS3 services. End users will be aware of an available 
interface (an IP address and some open ports mapped to each service) prepared to connect them to the contracted 
Service Providers. 

The SEP is broken down into two SSM's (Server Side Middleware), the SSMl/2 interfacing to SSI and SS2, and SSM3 
interfacing to SS3. The same structure is replicated at the SEL side which defines the SSMl/2 and SSM3 counterparts: 
OBU Side Middleware (OSMl/2 and 0SM3). 



C.1 Server Side Middleware for SS1 and SS2 

The SSMl/2 contain the functions that serve as interfaces between the S-Band Network Platform and: 

• the Service Centres; and 

• the Alternative Ground Networks (if any); 

in order to provide network independence and interoperability with existing service providers. The presence of OBU 
Side Middleware (OSMl/2) on the User Terminal is foreseen to interact with the Server Side Middleware (SSMl/2). 



Table C.1 : Functional description of SEP/SSM1/2 



SEP/SSM3 


Service-Level AAA 


The SSM1/2 performs the Service Authentication, Authorization and Accounting of both 
Service Providers and User Terminals. Different levels of service AAA are possible on the 
User Terminal side. The SSM1/2 can perform the Service AAA of the S-band SS (in case 
only this interface can be used to consume a type of service) or of the whole User 
Terminal (i.e. both interfaces, S-band SS and IP SS, can be used). It is evident that the S- 
band SS can be authenticated and authorized from a service point of view by the SSM1/2 
only if this interface has already authenticated and authorized at System level by the Hub. 
Finally, a User AAA is possible if different User can access a User Terminal. 


S-MIM Messaging 
Protocol (SMP) 
Manager 


The SSM1/2 uses high level protocols to perform AAA. For example SOAP (through IP 
SS) and S-MIM Messaging Protocol (through S-band SS) could be used: 

• Address Conversion: Service Providers address User Terminals and Users using 
public addresses such as: user ID, International Phone Number, nick name, etc. 
The SSM1/2 performs addressing conversion in order to deliver the message to 
the right User Terminal using the IP Address of the available interface of the User 
Terminal (S-band SS or IP SS) which will be used to deliver (or to receive) 
messages (Switching Functionaiity). 

• Message Protocol Conversion: the SSM1/2 manages the protocol conversion 
from/to the SOAP Protocol, used to communicate with Service Providers, to/from 
the S-MIM Messaging Protocol used to deliver or receive messages to/from User 
Terminals [Session Functionaiity). 


QoS Negotiation 


QoS Negotiation: the SEP communicates with the SS1 and SS2 Service Providers in order 
to negotiate, on the behalf of the Hub, the QoS guarantees of each service flow. 


SMS/MMS Gateway 


It contains the SMS/MMS Gateway used to collect/deliver SMS/MMS messages from/to 
2G/3G/4G/PSTN Networks. 


SEP Location 
Register (SLR) 


The SEP collects most of the data required to perform the previous AAA processes directly 
from the SS1/SS2/SS3 Service Provider (they are the owner of the customer) and from the 
Hub/NCC which is the responsible of the S-band SS interface. 
The SLR is a common function for SS1/SS2 and SS3 services. 
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C.2 Server Side Middleware for SS3 

The Server Side Middleware for SS3 (SSM3) is the subsystem of the SEP which provides SS3 connectivity between 
S-MIM end users and SS3 Service Providers, which are typically located in terrestrial networks. 

The SSM3 at SEP should offer functionalities for the provision of the S3 services: 

1) Service-Level AAA: This functionality is the same as the one explained in clause C.l except for User AAA, 
which should be directly authenticated by the Service Provider. The 0SM3 elements (class D terminals) and 
SSM3 could help performing authentication functions for example in VoIP calls based on SIP REGISTER and 
also collect CDRs information. Regarding Two-way IP connectivity (just class D terminals). User AAA is out 
of the scope of S-MIM, in order to be as compatible as possible to any user application running in devices 
connected to the terminal, and no particular mechanism or protocol is imposed for AAA in this service. As an 
option or recommendation, 802. Ix or captive portal approaches could be implemented. 

2) VoIP service, including eCall: SSM3 should include an SIP/RTP proxy that performs call routing for users 
both in B3/C class terminals and behind D class terminals. Another SIP/RTP proxy should be placed at 0SM3 
that should authenticate class D terminal's end users locally and route outgoing and incoming voice calls 
to/from SSM3. Furthermore, no SIP/RTP proxy will be placed on every Hub in order to simplify the overall 
VoIP architecture, allowing horizontal handover (among Hubs). Instead, high capacity IP links interconnecting 
all the Hubs and SSM3 are contemplated. IPv4 to IPv6 addressing conversion at both 0SM3 and SSM3 is 
contemplated making use of SIP and RTP proxies; this approach avoids the use of tunnels to convey IPv4 
datagrams all across the S-MIM system which have a huge impact in the performance of the header 
compression mechanism at Link layer level. 

3) Generic Two-way-IP connectivity: This service is exclusive for class D terminals. Both 0SM3 and SSM3 
should have elements that enable this service. A PEP (Performance Enhanced Proxy) could be placed both at 
0SM3 and SSM3 as an option. In order to solve the problem of IPv4 to IPv6 addressing conversion, IPv6 
tunnelling encapsulation should be performed at 0SM3 and SSM3. 
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Figure C.1 : The SEL/OSIVIS and SEP/SSIVIS for SS3 architecture and interfaces 

Figure C.l shows the high level architecture and the interfaces involved in the Service Enabling Platform and Service 
Enable Layer modules for SS3, as described in Table C.2. 
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Table C.2: Functional description of SEP/SSM3 



SEP/SSM3 


SIP Proxy 


SSM3 should include a high capacity SIP proxy that performs call routing functions for all 
the S-MIM VoIP capable SS3 terminals. It will manage all the SIP signalling going to or 
coming from the VoIP terminals in S-MIM including eCall service. 


RTP Proxy 


Working in conjunction with the high capacity SIP Proxy, this module implements the 
required functionalities to handle VoIP voice packets (RTP) for only the VoIP calls 
(including eCalls) between VoIP capable SS3 terminals and terminals located at external 
networks (beyond ITSPs). Other features are listed below: 

• Full IPv4 to IPv6 addressing translation for RTP voice packets. That is, the RTP 
proxy should have two physical interfaces, one with global IPv6 address (facing 
S-MIM terminals) and one with public IPv4 address (facing Internet Telephony 
Service Providers). These physical interfaces may coincide with the SIP proxy 
ones. 

• Call control and direct interaction with SIP proxy to provide further IPv6 to IPv4 
addressing conversion for RTP packets. 


IP Gateway 


This element is exclusive for class D terminals offering Two-way IP connectivity service. 
Both 0SM3 and SSM3 should have elements that enable this service. Regarding the 
features concerning SSM3 we have the following: 

• A PEP (Performance Enhanced Proxy) could be placed both at 0SM3 and SSM3 
as an option. 

• In order to solve the problem of IPv4 to IPv6 addressing conversion, IPv6 
tunnelling encapsulation should be performed at 0SM3 and SSM3. 

• Due to the fact that IPv4 addressing at D class terminal LAN will be private. 
Network Address Translation function between IPv4 private addressing and 
public IPv4 address pool should be performed at the IP gateway for data Internet 
access. This is performed once the IPv6 encapsulation is taken out from the 
original IP packet. 

• User AAA for Two-way IP connectivity is out of the scope of S-MIM, in order to be 
as compatible as possible to any user application running in devices connected 
to the terminal, and no particular mechanism or protocol is imposed for AAA in 
this service. As an option or recommendation, 802.1 x or captive portal 
approaches could be implemented in 0SM3. 



From the point of view of a ground segment ITSP, the S-MIM system should provide a single SIP point of access in 
case of an incoming voice call from terrestrial networks such as ISDN or PSTN. The calling user dials a prefix number 
that reaches the SSM3's SIP proxy but once there, the SSM3 knows about the location information (that is IPv6 address) 
of the called party, which is some end user behind a SS3 capable Terminal. In Figure C.l this access point, 
{I_sep_voip_ s}, has been located at the NCC where the SEP might be placed. The location of the interface at hand is 
not important provided that it has access to the database linking a user behind a SS3 terminal to an IPv6 address. 

In case that this end user is behind a class D terminal, the calling user should know an additional prefix that identifies 
this particular class D terminal SIP proxy. That way, VoIP call routing will be much easier for SSM3 SIP proxy. As 
terminal D usage is contemplated for emergency scenarios, the previous assignation of terminal D prefixes can be 
affordable and reasonable. 
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Annex D (informative): 
IVIanagement Plane 



Network Management is the responsibility of the network and service provider(s), and is not formally specified for 
operation of the S-MIM system. Instead, recommendations are indicated below. 

A set of minimum network management functions for S-MIM system is defined, which may be complemented with 
functions provided by service providers. 

A common Management Plane architecture is defined for both forward and return links. 

An example of requirements for management of terminals and network devices is given in the DVB specification [i.7]. 
An S-MIM network management system is considered to be included within the Hub/NCC, where it is possible to 
identify two logical entities: 

• The Remote Management System (RMS), which is in charge of the management and modification of the 
functioning of a device under its control. 

• The Firmware Update System (FUS) which stores and manages the list of firmware versions available. 

Both entities communicate with the network/service providers, devices to be managed, and with device manufacturers. 
The SOAP protocol over secure HTTP can be used for communicating with the device manufacturers (for provision of 
firmware updates and management tools), and with service providers. Communications between FUS and the 
manufacturer can be also performed using FTP or HTTP. 

SOAP/Https can also be used for the communication between management entities and network devices because a 
WAN interconnection is usually available. The CWMP or SNMP protocols on top of this protocol stack any also be 
used manage the network elements. 

For remote management of user terminals the characteristics of the S-Band radio interface require use of management 
protocols on top of a UDP/IP stack. 

The following figure shows the main protocols involved in management. With regard to the remote terminal 
management, the main operations are carried out via SNMP/UDP/IP, while the delivery of files (such as firmware 
upgrades) is carried out with the FLUTE protocol. 
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Figure D.I: Terminal Management Plane Protocols 
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